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Sir: 

This is an appeal under 37 CFR § 41.31 to the Board of Patent Appeals and 
Interferences of the United States Patent and Trademark Office from the final rejection of 
claims 1-41 of the above-identified patent application. Claims 1-13, 15-39 and 47-51 were 
rejected in the Final Office Action dated August 9, 2005. This brief has been amended to 
address a non-compliance noted in a Notice of Non-Compliant Appeal Brief dated March 
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27, 2006. 

(1) REAL PARTY IN INTEREST 

Siemens Building Technologies, Inc. is the owner of this patent application, and 
therefore the real party in interest. 

(2) RELATED APPEALS AND INTERFERENCES 

An appeal was filed in a case having a similar disclosure, U.S. Patent Application 
Serial No. 09/967,338. The Appeal Brief was filed December 28, 2005. The Appeal is no 
longer pending because the Examiner has re-opened prosecution on the matter. 

(3) STATUS OF CLAIMS 

Claims 1-13, 15-39 and 47-53 are pending in the application. 

Claims 1-13, 15-39 and 47-51 stand rejected and form the subject matter of this 
appeal. Claims 1-13, 15-39 and 47-53 are shown in the Appendix attached to this Appeal 
Brief. 

(4) STATUS OF AMENDMENTS 

Applicants filed a Response to Office Action dated May 16, 2005 ("Response") 
responsive to an Office Action dated January 4, 2005. A Final Office Action dated June 28, 
2005 was designated by the Examiner to be responsive to the Response. 
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(5) SUMMARY OF THE CLAIMED SUBJECT MATTER 

Claim 1 is directed to a proprietary communication protocol for use in a system 
controller that includes an application controller and a plurality of applications for 
controlling a plurality of device controllers on a control network by using data relating to 
system points that correspond to data variables in the network. As shown in Figs. 1 and 2 
of the Application, an exemplary embodiment of the invention of claim 1 includes a system 
controller that includes an application controller in the form of NPRA 104, a plurality of 
applications in the form of applications 102, and a plurality of device controllers 1 12 and 
116. (See Specification at p.5, line 28 to p.6, line 17; see also id at p.8, lines 11-16). 

Referring again generally to claim 1, the proprietary communication protocol 
includes a plurality of predefined messages transmitted between the application controller 
and the applications for instructing the application controller to perform a function relating 
to a select system point. In the embodiment described in the Specification, the applications 
or clients 102 send messages to the NPRA 104 requesting various operations on system 
points or SPs. (See id. at p.8, line 1 1-16; see also p.14, lines 25-27; p.15, lines 14-15). As 
claimed, the predefined messages include messages for reporting to the application in 
response to the instruction. (See e.g. id at p. 18, lines 13-15 and lines 21-23). The 
plurality of messages includes a discover message transmitted by the applications to the 
application controller for inquiring whether a select system point is stored in a database of 
the application controller. (See e.g., id at p. 12, lines 19-21). 

The proprietary protocol includes a message identification field and a protocol 
identification field. (See, e.g., id. at Fig. 5, elements 162 and 164). 
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Claim 47 is directed to a proprietary communication protocol for use in a system 
controller that includes an application controller and a plurality of applications for 
controlling a plurality of device controllers on a control network by using data relating to 
system points that correspond to data variables in the network. As shown in Figs. 1 and 2 of 
the Application, an exemplary embodiment of the invention of claim 1 includes a system 
controller that includes an application controller in the form of NPRA 104, a plurality of 
applications in the form of applications 102, and a plurality of device controllers 112 and 
116. (See Specification at p.5, line 28 to p.6, line 17; see also id at p.8, lines 11-16). 

Referring again generally to claim 47, the proprietary communication protocol 
includes a plurality of predefined messages transmitted between the application controlled 
and the applications for instructing the application controller to perform a function relating 
to a select system point. In the embodiment described in the Specification, the applications 
or clients 102 send messages to the NPRA 104 requesting various operations on system 
points or SPs. (See id at p.8, line 1 1-16; see also p.14, lines 25-27; p. 15, lines 14-15). As 
claimed, the predefined messages include messages for reporting to the application in 
response to the instruction. (See e.g. id. at p. 18, lines 13-15 and lines 21-23). 

The proprietary protocol includes a message identification field and a 
protocol identification field. (See, e.g., id at Fig. 5, elements 162 and 164; p. 9, lines 15- 
16). The protocol also includes a field for indicating at least one element value of the select 
system point. (See id. at Fig. 5, element 174; p. 10, lines 38-32). The protocol further 
includes a field for determining a format for displaying said element values. (See id. at Fig. 
5, element 176; p.l 1, lines 1-6). 
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(6) GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Whether claims 1-5, 8, 10-13, 15-16, 18-22, 25, 27-34, 36-39 and 47-51 are 
anticipated by U.S. Patent No. 6,763,040 to Hite (hereinafter "Hite"). 
Whether claims 9 and 17 are unpatentably obvious over Hite. 

(7) ARGUMENT 

I. Hite Does Not Anticipate Claim 1 

In the January 4, 2005 office action, the Examiner rejected claim 1 as allegedly 
being anticipated by Hite. As will be discussed below in detail, Hite does not teach, show 
or suggest each and every element of claim 1 . As a consequence, it is respectfully 
submitted that the anticipation rejection of claim 1 should be reversed. 

A. Hite 

Hite discloses a protocol that includes a packet protocol. The packet protocol 
includes a protocol field, a length of data field, a data field, and a checksum. The protocol 
field indicates the type of protocol. The length of data field lists the length, in bytes, of the 
data field. The data field contains the sub protocol data and the checksum determines the 
integrity of the packet. (Hite at Abstract). In pertinent part, Hite further teaches a number 
of messages that manipulate something that is referred to as an "Asynchronous Notification 
List". (Id. at column 34, lines 9-67). 

Hite further goes onto disclose that the "included message protocol and its packet 
are designed to be sent independent of any transport protocol. Thus, this message can be 
sent by a TCP/IP protocol over any connection or by a lontalk protocol, which is based on 
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the phastlink protocol developed by Panja, Inc." (Id at col. 51, lines 14-18). 



6 



1867-0084 
2001P18038US 

B. Hite Does Not Teach a LON Network Variable Type 

Hite fails to teach, show or suggest "a message for subscribing for notification of 
changes of in a value of at least one select network variable, the at least one select network 
variable [having] a LON specific data type", as recited in claim 1 . More specifically, Hite 
does not appear to teach the use of LON specific data type network variables at all, much 
less a message subscribing for notification of a change in one of the network variables. 

In particular, the only mention of "LON" in Hite is in the above-quoted passage 
where it is stated that the messages of Hite may be sent over a lontalk protocol. (Hite at 
col. 51, lines 14-20). However, Hite does not actually teach or suggest protocol messages 
that use LON network variables. Instead, Hite simply employs the lontalk communication 
transport protocol to send the custom messages. Hite teaches a specific network variable 
protocol, and does not teach or suggest that its specific network variables use the LON data 
types. (See id. at cols. 13-51). Indeed, Hite does not mention the use of a LON control 
system at all, just that its data messages may be sent via Lontalk transport protocol 

Moreover, use of a Lontalk transport protocol does not, without more, inherently 
teach use of LON specific data types for network variables. In particular, the Examiner has 
not established that use of the Lontalk transport protocol with the message formats taught 
by Hite would result in a "network variable having a LON specific data type". A network 
variable is a variable used on a network, as is apparent by the language of the claim, and the 
data type is a definition of the format of the data values for the network variable. For 
example, if a temperature reading is a network variable, the data type could be "degrees 
Fahrenheit", "degrees Celsius", or the like. 

The data type used by a "network variable" is unrelated to the transport protocol 
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used. The transport protocol, as is known in the OSI standard, merely facilitates transport 
of data messages between logical end points, and is unconcerned with the content of the 
messages. Accordingly, a transport protocol does not describe a data type for a network 
variable. 

As a consequence, the mere fact that Hite teaches elements that may be considered 
to be network variables, and that Hite teaches that a Lontalk protocol may be used as a 
"transport protocol", does not constitute a teaching the Hite teaches a "network variable 
having a LON specific data type". While Hite may arguably teach a "network variable" 
that is contained within a Lontalk- formatted message, Hite does not teach the network 
variable itself having a LON specific data type. 

The Examiner 's Arguments 

In the Final Office Action, the Examiner addressed the above-recited argument in 
page 2 in the Response to Arguments section. The Examiner's arguments are set forth 
below: 

In response to the argument that the network variable having a LON specific data type is not taught 
by the prior art, Hite disclosed using Lontalk as a means for communication between a master and a 
PC (Col 5 1 , lines 1 0-20). For communication to be possible between master and PC the data has to 
conform to the Lontalk protocol, which is LON specific. 

Applicants disagree with the Examiner's logic. Hite does not teach that 
communication of data via the Lontalk transport protocol is impossible without using LON 
specific data types. The Examiner appears to presume that if the Lontalk transport protocol 
is used, then all network variable data provided within the Lontalk transport protocol 
messages must have a LON specific data type. While the message formats may be required 
to conform to the Lontalk transport protocol, there is no teaching in Hite that the network 
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variable data contained within those messages must be of any particular data type. 

It is noted that the Examiner appears to have interpreted the term "network variable" 
largely correctly, indicating that values for "input channel", "output channel", and "level 
changes" constitute network variables. (Final Office Action at p.2). However, nothing in 
Hite requires those values to have a LON specific data type. The Examiner has not 
established a prima facie case that values for "input channel", "output channel", and "level 
values", which are plainly application-layer specific, require any modification in data type 
arising from the use of the Lontalk transport protocol. 

By contrast, the protocol of the present invention is clearly intended to use the LON 
network variable types. Claim 1 specifically mentions that the at least one network variable 
is one of the LON specific data types. Pages 6 and 7 of the specification discuss the same. 
The present invention discloses an extension of the LON network variable implementation, 
not simply the use of the transport network. 

Transport Layer Overhead Are Not Network Variables as Claimed 
Moreover, even if Hite did teach the use of LON network variables as claimed, it 
does not appear to teach a protocol message that subscribes to changes in the value of such 
a network variable. In particular, claim 1 recites that "said plurality of message include a 
message for subscribing for notification of changes in a value of at least one select network 
variable . . . having a LON specific data type". Thus, the claimed network variable must 
be one for which notification of changes in value may be subscribed to. 

Hite only clearly teaches one set of values that may be considered to be "LON 
specific". The only values that clearly are affected by the use of the Lontalk transport layer 
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protocol relate the message overhead information,, and not the actual device data or network 
variable values. Thus, the Examiner could argue that the Lontalk transport overhead 
information constitutes one or more "network variables". 

However, Hite fails to teach the message subscribing to notification of changes to 
such transport layer overhead values. Accordingly, such transport layer overhead values 
cannot constitute "network variables" as claimed. 

Summary of Arguments 

If network variables are interpreted normally to constitute variables that represent 
values relating to the application on the network (i.e. device operation), then Hite fails to 
teach network variables having a LON specific data type. Alternatively, if network 
variables is interpreted broadly to include Lontalk transport layer overhead values, then 
Hite fails to teach "a message for subscribing for notification of a value of such a Lontalk 
transport layer overhead value. 

Accordingly, Hite fails to anticipate claim 1. As a consequence, it is respectfully 
submitted that the rejection of claim 1 as being anticipated by Hite is in error and should be 
reversed. 

II. Claims 2-25 

Claims 2-25 also stand rejected as allegedly being unpatentable over Hite. Claims 
2-25 all depend from and incorporate all of the limitations of claim 1 . Accordingly, for at 
least the same reasons as those set forth above in connection with claim 1 , it is respectfully 
submitted that the anticipation rejections of claims 2-25 should be reversed. 
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A. The Rejection of Claims 6 and 7 Should be Reversed for Additional Reasons. 

The rejection of claims 6 and 7 should be reversed for additional reasons. Claims 6 
and 7 include a limitation directed to the data type value "selected from a group that 
includes a standard network variable type and a user defined network variable type". Thus, 
not only is the data type identified in the message, but the data type is selected from one of 
a group of possible data types that include a standard network variable type and a user- 
defined network variable type. 

In the rejection of claim 6, the Examiner contended that the selection from a group 
that includes a standard data type and a user-defined data type is taught by Hite at col. 1 1 , 
lines 40-50 and col. 55, lines 30-40. (Final Office Action at p.4). These passages do not 
describe that data value types can be user-defined, nor that they are "standard" user types. 
Although it appears that the data types of Hite are not user-definable, and therefore 
"standard", there is no indication that the data value type field contains a value indicative of 
one of a group including both a standard network variable type and a user definable 
network variable type. In other words, it appears that only standard network variable types 
are available. 

It is therefore respectfully submitted that the Examiner has failed to make out a 
prima facie case of anticipation. Accordingly, for reasons independent of those discussed 
above in connection with claim 1, it is respectfully submitted that the obviousness rejection 
of claims 6 and 7 should be reversed. 
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B. The Rejection of Claim 19 Should be Reversed For Other Reasons 

The rejection of claim 19 should also be reversed for reasons in addition to those set 
forth above in connection with claim 1 . 

Claim 19 recites that the "predefined messages include a message including 
instructions for canceling said overriding instructions". Claim 17, upon which claim 19 
depends recites an "override" message type. Thus, claim 19 recites a predefined message 
wherein a previously sent override message (per claim 1 7) should be canceled. (See 
Application at Figs. 10 and 1 1, for examples of these messages). 

Hite does not disclose such an override cancellation message. Hite merely teaches 
that a "master" device can be used to force a change in level of another device. Even if this 
were an override command, Hite does not teach a way in which an override message may 
be canceled using a different message type, as called for in claim 19. 

The Examiner cites Hite at column 21, lines 55-60 as teaching a "message including 
instructions for canceling said overriding instruction" (Final Office Action at p. 6). The 
cited portion of Hite is set forth below: 

Level Value (Device > Master) 

This message is used to indicate, to the master, that a device/port/level value has 

changed. 

Message and Parameters 

(Hite, col. 21, lines 55-60). The above cited language merely discloses a message that 
informs another node of a change in a network variable. A message informing a node of a 
value change does not operate to "cancel" anything. It merely informs the node of a status. 

Because the Examiner has failed to cite any portion of Hite that teaches or suggests 
"a message including instructions for canceling said overriding instructions" as claimed in 
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claim 19, the Examiner has failed to make out a prima facie case of anticipation with regard 
to claim 19. Accordingly, for reasons independent of those discussed above in connection 
with claim 1, it is respectfully submitted that the anticipation rejection of claim 19 over Hite 
should be reversed. 

C. The Rejection of Claim 20 Should be Reversed For Other Reasons 

The rejection of claim 20 should also be reversed for reasons in addition to those set 
forth above in connection with claim 1. 

Claim 20 recites that the "predefined messages include a message requesting a 
report as to whether said specified one of the network variables has been overridden". 
Thus, claim 20 recites a predefined message wherein a report is requested relating to an 
override. Hite does not disclose such an override report message. 

As with claim 19, the Examiner cites Hite at column 21, lines 55-60 as teaching a 
"message requesting a report" (Final Office Action at p.7). The cited portion of Hite is set 
forth below: 

Level Value (Device > Master) 

This message is used to indicate, to the master, that a device/port/level value has 

changed. 

Message and Parameters 

(Hite, col. 21, lines 55-60). The above cited language merely discloses a message that 
informs a node of a change in a network variable. A message informing a node of a change 
does not operate to "request" anything, much less a "report". It merely informs the node of 
a status. 
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Because the Examiner has failed to cite any portion of Hite that teaches or suggests 
"a message requesting a report as to whether said specified one of the network variables has 
been overridden" as claimed in claim 20, the Examiner has failed to make out a prima facie 
case of anticipation with regard to claim 20. Accordingly, for reasons independent of those 
discussed above in connection with claim 1 , it is respectfully submitted that the anticipation 
rejection of claim 20 over Hite should be reversed. 

D. The Rejection of Claim 21 Should be Reversed For Other Reasons 

The rejection of claim 21 should also be reversed for reasons in addition to those set 
forth above in connection with claim 1 . 

Claim 21, like claim 19, recites that the "predefined messages include a message 
including instructions for canceling said overriding instructions". As discussed above in 
connection with claim 19, Hite does not disclose such an override cancellation message. 
Hite merely teaches that a "master" device can be used to force a change in level of another 
device. Even if this were an override command, Hite does not teach a way in which an 
override message may be canceled using a different message type, as called for in claim 21 . 

As discussed above, the Examiner cites Hite at column 21, lines 55-60 as teaching a 
"message including instructions for canceling said overriding instruction" (Final Office 
Action at p.7). The cited portion of Hite is set forth below: 

Level Value (Device > Master) 

This message is used to indicate, to the master, that a device/port/level value has 

changed. 

Message and Parameters 

(Hite, col. 21, lines 55-60). The above cited language merely discloses a message that 
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informs a node of a change in a network variable. A message informing a node of a change 
does not operate to "cancel" anything. It merely informs the node of a status. 

Because the Examiner has failed to cite any portion of Hite that teaches or suggests 
"a message including instructions for canceling said overriding instructions" as claimed in 
claim 21 , the Examiner has failed to make out a prima facie case of anticipation with regard 
to claim 21 . Accordingly, for reasons independent of those discussed above in connection 
with claim 1, it is respectfully submitted that the anticipation rejection of claim 21 over Hite 
should be reversed. 

IV. Claim 26 

Claim 26, like claim 1, has limitations directed to a protocol having a message that 
subscribes to changes of values in a network variable, and wherein the network variable has 
a LON data type. Accordingly, for at least the same reasons as those set forth above in 
connection with claim 1, it is respectfully submitted that the rejection of claim 26 over Hite 
should be withdrawn. 

V. Claims 27-41 

Claims 27-41 depend from and incorporate all of the limitations of claim 26. 
Accordingly, for at least the same reasons as those set forth above in connection with claim 
26, it is respectfully submitted that the rejection of claims 27-41 over Hite should be 
reversed. In addition, the rejection of claim 35 should be reversed for the additional 
reasons set forth above in connection with claim 19. Similarly, the rejection of claim 36 
should be reversed for the additional reasons set forth above in connection with claims 19 
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and 20. 



(8) CONCLUSION 

For all of the foregoing reasons, claims 1-41 are not anticipated under 35 U.S.C. § 
102(b). As a consequence, the Board of Appeals is respectfully requested to reverse the 
rejection of these claims. 



Respectfully submitted, 

Harom C. Moore 
Attorney for Applicants 
Attorney Registration No. 37,892 
Maginot Moore & Beck 
Bank One Center Tower 
1 1 1 Monument Circle, Suite 3250 
Indianapolis, Indiana 46204-5115 
Telephone: (317)638-2922 
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CLAIM APPENDIX 



Claim 1 . A proprietary communication protocol for use in a system controller that includes 
an application controller and a plurality of applications for controlling a plurality of device 
controllers on a control network by using data relating to system points that correspond to 
data variables in the network, said proprietary communication protocol comprising: 

a plurality of predefined messages transmitted between the application controller 
and the applications for instructing the application controller to perform a function relating 
to a select system point, and for reporting to the applications in response to said instruction, 
said plurality of messages include a discover message transmitted from the applications to 
the application controller for inquiring whether the select system point is stored in a 
database of the application controller; 

a message identification field for identifying a select message from said plurality of 
messages; and, 

a protocol identification field for identifying said select message as being 
transmitted via said proprietary communication protocol. 

Claim 2. The proprietary communication protocol as defined in claim 1 wherein said 
proprietary communication protocol is embedded into a communication protocol of the 
control network. 

Claim 3. The proprietary communication protocol as defined in claim 1 further including a 
system point identification field for identifying the select system point. 

Claim 4. The proprietary communication protocol as defined in claim 3 wherein said 
system point identification field is a point unique identification (PUID) field for identifying 
the select system point by a unique identification number that is assigned to the select 
system point. 
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Claim 5. The proprietary communication protocol as defined in claim 3 wherein said 
system point identification field is a name identification field for identifying the select 
system point by a user-defined name that is assigned to the select system point. 

Claim 6. The proprietary communication protocol as defined in claim 1 further including a 
priority field for determining whether data relating to the select system point can be written 
to. 

Claim 7. The proprietary communication protocol as defined in claim 1 further including a 
priority field for determining whether data relating to select system point can be overridden. 

Claim 8. The proprietary communication protocol as defined in claim 1 further including a 
transaction identification field for uniquely identifying said select message from the 
plurality of predefined messages. 

Claim 9. The proprietary communication protocol as defined in claim 1 further including a 
field for indicating whether said select message is a last message being transmitted from the 
application controller to the applications. 

Claim 10. The proprietary communication protocol as defined in claim 1 further including a 
field for indicating at least one element value of the select system point. 

Claim 11. The proprietary communication protocol as defined in claim 10 farther including 
a field for determining a format for displaying said element values. 

Claim 12. The proprietary communication protocol as defined in claim 1 further including a 
notification field for indicating at least one type of changes in the data relating to the select 
system point for which at least one of the applications desires subscription. 
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Claim 13. The proprietary communication protocol as defined in claim 12 wherein said 
changes include a change of value, a change of state and a change of quality relating to the 
select system point. 

Claim 15. The proprietary communication protocol as defined in claim 1 wherein said 
discover message refers to the select system point via a unique identification number 
associated with the system point. 

Claim 16. The proprietary communication protocol as defined in claim 1 wherein said 
discover message refers to the select system point via a user-defined name that is assigned 
to the select system point. 

Claim 1 7. The proprietary communication protocol as defined in claim 1 wherein said 
plurality of messages include a message transmitted from the application controller to the 
application in response to said discover message to report that the select system point is 
stored in said database. 

Claim 18. The proprietary communication protocol as defined in claim 1 wherein said 
plurality of messages include a message transmitted from the applications to the application 
controller for subscribing for changes in the data relating to the select system point. 

Claim 19. The proprietary communication protocol as defined in claim 1 8 wherein said 
changes include a change of value, a change of state and a change of quality relating to the 
select system point. 

Claim 20. The proprietary communication protocol as defined in claim 18 wherein said 
plurality of messages includes a message transmitted from the applications to the 
application controller for unsubscribing for changes in the data relating to the select system 
point. 
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Claim 21. The proprietary communication protocol as defined in claim 18 wherein said 
plurality of messages include a message transmitted from the application controller to the 
applications reporting of said changes in the data relating to the select system point in 
response to said subscription message transmitted from the applications. 

Claim 22. The proprietary communication protocol as defined in claim 1 wherein said 
plurality of messages includes a message transmitted from the applications to the 
application controller for overriding or writing new values in the data relating to the select 
system point. 

Claim 23. The proprietary communication protocol as defined in claim 22 wherein said 
overriding and writing message is accepted by the application controller if a priority of an 
application transmitting said message is greater than or equal to a priority of the data 
relating to the select system point. 

Claim 24. The proprietary communication protocol as defined in claim 23 wherein said 
plurality of messages includes a message transmitted from the applications to the 
application controller for releasing said priority of the data relating to the selected system 
point to allow an application having a lower priority than said priority of the data to 
override or write new value in the data relating to the select system point. 

Claim 25. The proprietary communication protocol as defined in claim 1 wherein said 
plurality of messages includes a message transmitted from the applications to the 
application controller for requesting query of the data relating to at least one of the system 
points for specified information. 

Claim 26. The proprietary communication protocol as defined in claim 25 wherein said 
query message requests a report on all system points that have a write or override priority 
that is greater than or equal to a specified priority level of said query message. 
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Claim 27. The proprietary communication protocol as defined in claim 25 wherein said 
query message requests a report on all system points that conforms to a specified quality. 

Claim 28. The proprietary communication protocol as defined in claim 25 

wherein said query message requests a report on all system points that a status of at least 

one node of the control network. 

Claim 29. The proprietary communication protocol as defined in claim 1 wherein said 
plurality of messages includes a message transmitted from the applications to the 
application controller for canceling a previously transmitted message. 

Claim 30. The proprietary communication protocol as defined in claim 2 wherein said 
plurality of messages includes a message transmitted from the applications to the 
application controller for canceling a previously transmitted message. 

Claim 3 1 . The proprietary communication protocol as defined in claim 1 wherein said 
plurality of messages includes a message transmitted from the applications to the 
application controller for instructing the application controller to query all of the data 
variables in the network operatively connected to the application controller to determine if 
any of the data variables have been overridden. 

Claim 32. The proprietary communication protocol as defined in claim 1 wherein each of 
the system points are identified by a unique numeric value. 

Claim 33. The proprietary communication protocol as defined in claim 1 wherein the 
system points are identified by a user-defined name. 

Claim 34. The proprietary communication protocol as defined in claim 1 wherein each of 
the system points include at least one element value. 
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Claim 35. The proprietary communication protocol as defined in claim 1 wherein the 
system points have an assigned write priority and an override priority. 

Claim 36. The proprietary communication protocol as defined in claim 1 wherein the data 
relating to the system points are stored in a database of the application controller. 

Claim 37. The proprietary communication protocol as defined in claim 36 wherein said 
database stores user-defined data relating to the system points. 

Claim 38. The proprietary communication protocol as defined in claim 37 wherein said 
database stores a unique identification value of the corresponding data variables in the 
network. 

Claim 39. The proprietary communication protocol as defined in claim 37 wherein said 
database includes field for storing an address of the corresponding data variables in the 
network. 

Claim 47. A proprietary communication protocol for use in a system controller that includes 
an application controller and a plurality of applications for controlling a plurality of device 
controllers on a control network by using data relating to system points that correspond to 
data variables in the network, said proprietary communication protocol comprising: 

a plurality of predefined messages transmitted between the application controller 
and the applications for instructing the application controller to perform a function relating 
to a select system point, and for reporting to the applications in response to said instruction; 

a message identification field for identifying a select message from said plurality of 
messages; 

a protocol identification field for identifying said select message as being 
transmitted via said proprietary communication protocol; 

a field for indicating at least one element value of the select system point; and 
a field for determining a format for displaying said element values. 
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Claim 48. The proprietary communication protocol as defined in claim 47 wherein said 
proprietary communication protocol is embedded into a communication protocol of the 
control network. 

Claim 49. The proprietary communication protocol as defined in claim 47 further including 
a system point identification field for identifying the select system point. 

Claim 50. The proprietary communication protocol as defined in claim 49 wherein said 
system point identification field is a point unique identification (PUID) field for identifying 
the select system point by a unique identification number that is assigned to the select 
system point. 

Claim 5 1 . The proprietary communication protocol as defined in claim 49 wherein said 
system point identification field is a name identification field for identifying the select 
system point by a user-defined name that is assigned to the select system point. 

Claim 52. The proprietary communication protocol as defined in claim 47 further including 
a priority field for determining whether data relating to the select system point can be 
written to. 

Claim 53. The proprietary communication protocol as defined in claim 47 further including 
a priority field for determining whether data relating to select system point can be 
overridden. 
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